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ABSTRACT 


It is proposed to create a fully "open" architectural specification for standardized space 
mission command and control. By being open, i.e., independent of any particular 
implementation, diversity and competition will be encouraged among future commercial 

suppliers of space equipment and systems. Customers of the new standard capability are 
expected to include: F y 


o The civil space community (e.g., NASA, NOAA, international Agencies) 
o The military space community (e.g., Air Force, Navy, intelligence), 
o The emerging commercial space community (e.g., mobile satellite service providers) 


INTRODUCTION 

In response to declining space budgets, the U.S. civil and military space communities both 
have a critical need to significantly reduce the cost of operating spacecraft while 
Simultaneously accommodating requirements for increased mission flexibility and 
capability. The emerging commercial space community has a similar need for low-cost "off 
the shelf command and control systems that reduce the need for capital and operating 
investment. ^ F 5 

Standardization has emerged as a key weapon in the conflict between new demands for 
space mission complexity and increasingly limited space mission budgets. The command 
and control of space mission systems is an area that is ripe for standardization. For lack of 
standards or guidance, space mission command and control is (by and large) re-invented 
lor each mission; this drives up cost because a constant cycle of system redesign results in 
customized, non-automated operations that are highly labor intensive. 

There is a pressing need to develop and emplace new standard user services that allow 
many different types of spacecralt, and their supporting ground networks, to appear 
basically harmonious from the perspective of ground controllers. With such capabilities 
the spiral of constant redesign can be broken, automation may be deployed, and operations 
and maintenance budgets can be contained. F 

The new services should: 

o exploit rapid ongoing improvements in onboard data processing, storage and autonomy 
capabilities by encouraging the spacecraft designers to present simpler, more consistent 
and more mission-independent interfaces to ground operators; 


1213 

< 2-7 





o import off-the-shelf technologies by integrating a wide range of emerging commercial 
data processing and data communications capabilities into cohesive systems that 
support high performance space mission command and control; 

o enable the mission-independent operation of spacecraft and their supporting ground 
networks by small teams of multidisciplinary personnel whose productivity is leveraged 
by the the widespread deployment of automation; 

o be backwards-compatible with existing space systems so that a smooth transition from 
the present to the future may be observed. 

Many off-the-shelf capabilities currently exist; the primary challenge is to import these 
diverse technologies and to system engineer them into an integrated solution which satisfies 
the unique requirements of space mission operations. 

It is therefore proposed to develop and functionally specify a Space Project Mission 
Operations Control Architecture - "SUPERMOCA" - which will provide the open systems 
framework around which the integration and demonstration of multi-vendor 
implementations of the new approach may occur. 


TECHNICAL CONTEXT 

To control a remote spacecraft, the user formulates command directives, transmits them, 
monitors their execution, and takes corrective action in case of anomalous behavior. The 
spacecraft executes the command directives using various levels of onboard autonomy. 
The control center and the spacecraft exchange information via a space communications 
system that includes both ground and space/ground networks. 

Users in the control center also perform a similar set of actions to configure, monitor and 
control the remote ground data acquisition stations which are supporting the spacecraft. 
To facilitate automation and to reduce human staffing needs, the SUPERMOCA should 
promote a unified approach towards the command and control of the spacecraft and its 
supporting ground systems. 

In the terminology of Open Systems Interconnection (OSI), the SUPERMOCA resides 
within the Application layer and draws upon underlying lower layer space communications 
services. 

Figure- 1 shows the SUPERMOCA operating over a space data network containing: 

o Standardized space/ground data channels, as defined for the civil mission community 
by the Radio Frequency and Modulation standards defined by the Consultative 
Committee for Space Data Systems (CCSDS). 

o Standardized space/ground networks and data links, as defined by the CCSDS 
Recommendations for Packet Telemetry, Telecommand and Advanced Orbiting 
Systems. 

o Standardized upper layer protocols, operating efficiently in a "skinny stack" 
configuration that is currently being defined by the joint NASA/DoD "Space 
Communications Protocol Standards" (SCPS) development program. The SCPS stack 
provides fully secure and reliable file and message transfer services in support of the 
SUPERMOCA layer. 
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Figure 1 . Context of Space Mission Control and Command 













ELEMENTS OF THE SUPERMOCA 


The SUPERMOCA provides an "upwards" mission control service interface to the mission 
planning systems which are used to construct the broad profile of desired mission 
activities. "Downwards" it draws upon a space communications service provided by a 
stack of underlying standard protocols. Figure 2 shows these service relationships, and 
postulates a possible internal organization of the layer. 

The potential to achieve "backwards compatibility" with existing spacecraft is fundamental 
to the SUPERMOCA concept: this may be accomplished by locating all of the new 
SUPERMOCA architectural elements in the control center, and interfacing with the 
existing communications services that are possibly unique to that spacecraft. By 
retrofitting existing spacecraft into the SUPERMOCA, a smooth and rapid transition to the 
future is facilitated. 

As currently envisaged, the SUPERMOCA contains five elements. Three of these 
elements (the Control Interface, the Decision Support Logic and the Space Messaging 
System) form the heart of the actual process control system. The remaining two elements 
(the Data Architecture and the System Management Architecture) supply the framework 
within which the other elements operate. Because they have great significance throughout 
entire mission lifecycle, the Data Architecture and the System Management Architecture 
also frame the Mission Planning System. 

o Control Interface 

The Control Interface provides a human-oriented mechanism whereby a flight controller 
can specify and monitor the desired sequence of operations to be conducted in a remote 
system. It also provides the translation between high-level human directives and actual 
atomic-level commanded actions at the remote end. 

o Decision Support Logic 

The Decision Support Logic provides the capability whereby rules for command 
execution may be programmed into a distributed inference engine, which may be 
located wholly on the ground, wholly in space, or partitioned in varying degrees 
between the two. Commands may only be issued to end effectors in space when they 
conform to the flight rules that are programmed into the engine. Responses from end 
effectors will be compared against rule-based expectations, and the Decision Support 
Logic may take further preprogrammed command actions based on the observed 
performance. 

o Space Messaging System 

The Space Messaging System translates the machine-readable command calls from the 
user's Control Interface into standard-syntax messages which invoke the desired 
actions and responses in the remote space system. At the receiving end, generic device 
manipulations are translated back into concrete, atomic-level actions via the Control 
Interface. 
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Figure 2. Elements of the Control Architecture 



o Data Architecture 


The Data Architecture provides the mechanism whereby the precise characteristics of a 
concrete spacecraft system can be captured and described in abstract terms. It allows 
specific spacecraft devices to be described in standardized ways and for this 
information to be compiled into data dictionaries and encyclopedias. These data 
descriptions can be gathered starting at the earliest point in the project design lifecyle, 
thus supporting the progressive and seamless refinement, extension and translation of 
information from conceptual mission planning, through operations, and into post 
mission evaluation. 

o System Management Architecture 

Space mission process control fundamentally boils down to a problem of meeting 
mission success and safety -related criteria. The SUPERMOCA accomplishes this 
through the allocation and control of shared onboard resources, and by managing the 
relationships which describe how individual systems interact with the operating 
environment. To achieve this, "operations envelopes" are assigned to individual users, 
granting them certain "environmental rights" to conduct their operations and consume 
an allocated share of system resources, and certain "environmental privileges" to 
perturb the overall system environment. Providing users stay within their assigned 
envelopes, they are free to operate without detailed supervision. Potentially dangerous 
activities are precluded via a combination of software controls on command execution, 
plus hardware inhibits and interlocks which preclude unsafe or undesirable operations 
from occurring unless the system is prepared for them. 


DEVICE MODEL OF OPERATIONS 

The SUPERMOCA is conceptually founded in terms of a powerful "device model" of 
space mission command and control, which is illustrated in Figure 3. Within this model, 
all of the functions of the space mission are allocated to devices. A device may be physical 
hardware, a software module which serves as a control interface for hardware, a pure 
software function, or a combination of these. Each device has a function or functions 
which it performs: a pump circulates its working fluid; a motor rotates a solar panel; a 
software module calculates the pointing vector to the sun to guide the solar panel drive 
motor. 

Devices exist at many levels; normally, low-level devices will be aggregated into higher 
level devices, such that the operator can issue high level commands to the higher level 
devices, which will themselves orchestrate the function of the low-level devices to 
accomplish a complex function. A complete spacecraft (and, for that matter, its supporting 
ground system) is thus composed of many concrete low-level "space devices" which are 
assembled into complex subsystems that are integrated into an operating mission system. 

A space device has a standardized input/output interface through which the external world 
can know about it, or can control its behavior. This interface can be accessed by sending 
commands and receiving data or status messages. Attributes describe the device: they 
include information about the current operation of the device (such as temperature, mode, 
state, etc.) and descriptors of the device itself (such as serial number, date of manufacture, 
capacity, operating limits, etc.). Attributes can also include information about the intended 
use of the device, such as its redlined operational limits. 
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Figure 3. Device Model of Space Mission Control 




A device may exhibit one or more behaviors: an oven heats at a rate of 50 degrees per 
minute; software sends a particular response to an invalid command; an instrument will 
slew from one pointing direction to another without pointing at the sun. A device may 
issue messages indicating that specific events have occurred: a parameter may be out of 
limits, a function may have failed, or a hazardous condition might be noted. 

Relationships describe the context for a device. A device may be a part of a higher level 
assembly, connected to a particular data bus, communicating with another device over the 
data bus, powered by a a specific power supply, outputting a signal which becomes an 
attribute of another device, and configured with certain software to perform its functions. 

Device types are abstractions which provide a single definition for a family of related 
"virtual devices" (e.g., all valves, or all pumps, or all pointing actuators, or all voltage 
regulators, or all transponders share common features; which means that within a family, 
the same device interface exists for all of them). Therefore the general interface for a 
device type may be stored in dictionaries and encyclopedias that can be re-used and 
inherited across multiple space missions. 

By masking the uniqueness of a particular space system from its human operator, while 
providing the tools to progressively capture and exploit knowledge across multiple 
systems, the device model for space operations will enable the widespread and progressive 
standardization of the way in which human beings interact with complex, concrete 
systems in simple, abstracted ways. In particular, adoption of the device model will inject 
the discipline of standardized system description throughout all phases of space project 
design: this provides a powerful mechanism for creating a "design to operate" philosophy 
early in the project lifecycle. From the embryonic stages of mission planning, through 
operation and post mission evaluation, a seamless flow of data capture is created. 


CONCLUSION 

It is suggested that a completely standardized mechanism for space mission control is 
within 6ur reach. By importing and marrying many diverse off-the-shelf technologies, 
powerful new capabilities may be emplaced that contribute significantly to reducing the 
cost of operating space systems. Since the needed capabilities will be functionally defined 
in the form of an "open" specification, the SUPERMOCA will encourage a diverse set of 
compatible implementations to be placed on-the-shelf by the private sector, for shared use 
across the entire space mission community. 
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